Dynomotion

Group: DynoMotion Message: 11257 From: Hardy Family Date: 3/23/2015
Subject: Best way to prevent executing motion
Our machine has some spindle feedback, such as overtemperature alarm, which we treat as an estop condition.  Currently, the estop handler routine (running on the kflop) sends a HALT command to the PC, which is nice since we want to be able to resume the program once the spindle has cooled down.

I'm wondering, though, what is the best way to prevent the user from continuing the program when our machine is not yet able.  Currently, after the user responds to the "resume" dialog, then the program will start moving axes etc. - maybe without the spindle running.  All the while, my kflop program thinks it is in estop mode, but it's not really.

I tried disabling all axes, but this makes KMotion-CNC indicate a g-code error, which precludes clean recovery.  I get this even if I wait for the PC response to the HALT command.  Using the ESTOP command does not allow a clean recovery.

So is there anything "cleaner" that will prevent motion temporarily?

Regards,
SJH
Group: DynoMotion Message: 11259 From: Tom Kerekes Date: 3/24/2015
Subject: Re: Best way to prevent executing motion
Hi SJH,

I can't think of anything specifically.  Possibly force Feed Hold?

What "Resume" Dialog are you referring to?  Could your App check status before allowing Resume?

Regards
TK

Group: DynoMotion Message: 11260 From: Hardy Family Date: 3/25/2015
Subject: Re: Best way to prevent executing motion
The dialog is the one where the user is given a number of options to get going again, such as moving the a safe Z, then back to original X,Y etc.  This dialog only appears if the axes were jogged (if I remember correctly, I am not at the machine right now to confirm this).

Basically, what I am really after is a way to determine whether the PC program is sending move commands and, if so, some way to "veto" that movement if the machine is not ready.  This could be something running on the Kflop itself, or I don't mind if it is something on the PC side which examines a flag (like an I/O bit) that has the same veto effect.  Or maybe the PC could run a Kflop thread before resuming, and check the result before actually sending the next motion commands.

Putting it yet another way: I wish to be able to "lock" motion originating from g-code, without using DisableAxis() or similar events which disrupt the g-code program execution.

Maybe feed hold would help do this, but the user can still hit the button to un-feed-hold, which has the same lack of check to see if things can proceed safely (or at least I don't know how to do this with KMotion-CNC).  Although one could argue that the user needs to sort this out, I would still like to make this as bullet-proof as possible (especially given that the spindle might cost as much as a new Escalade :-)

Regards,
SJH


On Tue, Mar 24, 2015 at 12:30 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

I can't think of anything specifically.  Possibly force Feed Hold?

What "Resume" Dialog are you referring to?  Could your App check status before allowing Resume?

Regards
TK

Group: DynoMotion Message: 11262 From: Tom Kerekes Date: 3/25/2015
Subject: Re: Best way to prevent executing motion
Hi SJH,

We don't currently have a way to "lock motion originating from GCode" within KFLOP.  KFLOP operates at a low level and basically just does what it is told to do without any real knowledge of what on the PC originated the request.  It seems like the interlock would need to be in the Application level.  Possibly a check before allowing Cycle Start might be what you are describing.

I thought you were writing your own Application?  If using KMotionCNC the latest Test Version has an option to Invoke an "Action" before Cycle Start (as well as Before Feed Hold Resume).  See Tool Setup | M0-M30 | Cycle Start Action.  It might be that you can add a check there.

Another approach might be to Halt cleanly as you currently are, but then go into a mode where if you detect any motion while in over temperature you then Abort/disable axes.  That way things are always safe and only messy if the Operator explicitly attempts to resume while still in over temp.

There is a JOB_ACTIVE flag that is set in KFLOP when KMotionCNC starts GCode execution.   You might use that to immediately Abort the Job if it transitions true while in over temp. 

Regards
TK 

Group: DynoMotion Message: 11265 From: Hardy Family Date: 3/25/2015
Subject: Re: Best way to prevent executing motion
Hi Tom,

Thanks for the advice.  I will give it a try with the JOB_ACTIVE flag, and the latest version.  Maybe it would work if it just sends another PC_COMM HALT event?

Although I am developing an application, I would still like to be able to use KMotion-CNC for those cases where users want to be able to tweak things (at their own risk).  It's also very useful as a reference implementation while getting things working.

Regards,
SJH


On Wed, Mar 25, 2015 at 10:20 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

We don't currently have a way to "lock motion originating from GCode" within KFLOP.  KFLOP operates at a low level and basically just does what it is told to do without any real knowledge of what on the PC originated the request.  It seems like the interlock would need to be in the Application level.  Possibly a check before allowing Cycle Start might be what you are describing.

I thought you were writing your own Application?  If using KMotionCNC the latest Test Version has an option to Invoke an "Action" before Cycle Start (as well as Before Feed Hold Resume).  See Tool Setup | M0-M30 | Cycle Start Action.  It might be that you can add a check there.

Another approach might be to Halt cleanly as you currently are, but then go into a mode where if you detect any motion while in over temperature you then Abort/disable axes.  That way things are always safe and only messy if the Operator explicitly attempts to resume while still in over temp.

There is a JOB_ACTIVE flag that is set in KFLOP when KMotionCNC starts GCode execution.   You might use that to immediately Abort the Job if it transitions true while in over temp. 

Regards
TK